In the past, information management system applications, such as record management systems, had to be built by the supplier on a custom basis for the particular business or industry of the user/clients. The user/clients have specific requirements from a user interface perspective (UI) of the data that needs to be stored in the database, plus all the business rules behind each information field for inputting data. What happens is there is a core to the product that handles such items as bar codes, but nothing that actually is very specific to the user interface or the fields or the data that is being stored.
When the user/client places an order for a system application, technical people sit down with the user/client at an initial technical meeting and design a user interface, get user/client requirements, and then go back to the office and submit the information to the development group.
It could take probably a week from an investigation perspective to just get their requirements, i.e., just to get the initial design. Then, it has to be submitted to a software development group and scheduled for development. That could take anywhere from six weeks to several months depending on the work load of the development group, the complexity of the product, and how many projects the development group was doing at the same time. When the project is finally scheduled and the time starts for the implementation, the development group has to go back to the software base code and customize it by redesigning the software based on the requirements that were gathered. At that point the application is compiled, so all of that work is being done within a development environment. However, anywhere between one to five people are required to work full time on a particular project. This process can, depending on the complexity, take several weeks to complete for one user/client.
Once the product is compiled, then it has to be presented to the user/client for acceptance. Approximately 90% of the time that initial design is refused because user/clients always change their minds. They always have different requirements; they realize they forgot something; and/or something happened in their business process or workload that changes the initial requirements. Especially because there is such a long time span between the initial technical meeting and delivery, often times it comes back to the development group and has to be either rescheduled or sometimes rushed in. The developers must review the code . Again, it is back to the development stage, redesigning screens, adding new fields, redesigning the database, etc. Finally, it is compiled again and sent to the user/client and hopefully it is approved.
Once it is approved, it is delivered to the user/client. Six months down the line the user/client calls back and says, “We are changing our process and we are adding two new fields to the application. How much would it cost us, and how long will it take?” Again, it is exactly the same process. The same cycle is repeated because the development group must modify or redesign the user interface. The development group will need to redesign the databases and redesign the business rules that associate all of the elements together. So it is back to square one. The development group ends up starting from scratch, rebuilding the application, recompiling it, sending it to the user/client, and hopefully getting approval or acceptance the first time. Typically that does not happen, so it is sent back, and so on. So from a maintenance perspective and the perspective of the longevity of the product, both from a user/client perspective and supplier perspective, the customization process is pretty horrific.
If there were 25 user/clients, then there would be 25 versions of the product. While the core might be the same, everything around the core may be different. And as a matter of fact, even the core can be modified based on requirements or required work-arounds. So if something is required and cannot be easily implemented by simply adding to the product, the core would be modified. So for 100 user/clients, there are 100 versions of the product, and there is never a standard version of the product. From a maintainability perspective or improving the product, if there is a new feature that needs to be to added to the product, it would have to be customized for 100 different products, and each would then have to be supported and maintained.
Further, if a software bug is found, each of the 100 different products must be individually analyzed by going to that particular code and looking to see if the bug affected it because every code would be different.
Even today, it is believed that almost all of the customizable application products are targeted toward developers. The developer must be highly skilled technically in order to build the user interface and to associate the fields to data storage. In addition, almost none of these applications has any business logic behind it. Some of them may encapsulate some business logic into the fields, but there is no relationship between these fields.
Business logic includes, for example, data validation, date ranges, or rules about control dependency, which means controlling what can and cannot be entered on the screen. If a value is selected for a particular field, then other fields will be disabled, for example. All of the current applications are for UI designers or database designers.
For example, with Microsoft Access, it is possible for a non-technical end user to build an application dragging and dropping fields onto a form and then building a database. It is necessary to be a technical developer to connect the two, because the link between the database and the fields is not there. The links between the fields themselves on the screen and in the database are done by a developer and not by an end user.
In summary, in the past and in the current state of the art today, it could easily take months and sometimes years from the time that a sales person and/or a professional services technical support person obtains the requirements of a user/client to when a user/client is able to implement a system.
A system which would be able to reduce the design time and implementation time to a matter of days or weeks, and maybe months if it is a large company, has long been sought by but has eluded those skilled in the art.